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Description 

Field of the Invention 

[0001] The invention relates generally to network se- 
curity, and more specifically to techniques for managing 
Virtual Private Network (VPN) communications. 

Background of the Invention 

[0002] The need for creating secure logical networks 
over public and insecure communication lines, such as 
the Internet, continues to grow. Organizations desire and 
many times require secure communications with remote 
clients or services. As a practical matter, dedicated com- 
munication lines and equipment are not viable options, 
since these are unnecessarily expensive and require on- 
going maintenance and support. Thus, organizations 
have opted for a less expensive option and an easier 
option to implement and deploy. This option is referred 
to as a Virtual Private Network (VPN). 
[0003] A VPN uses an insecure network (e.g., Internet 
or public telecommunications infrastructure) for providing 
secure communications between remote clients or serv- 
ices. A VPN requires participants to have a common in- 
frastructure to support common encryption, decryption, 
security, and certain protocols. Data is encrypted from 
one participant and tunnelled using a secure protocol to 
another participant, where that data is decrypted and 
consumed. In some cases, even the address of the par- 
ticipants in a VPN is encrypted. 
[0004] With VPN techniques there are local computing 
environments associated with local clients or services 
and a remote computing environments associated with 
remote clients of services. Conventionally, each local cli- 
ent needs to support VPN communications and directly 
establish secure communications (e.g., Secure Sockets 
Layer (SSL) or Transport Layer Security (TLS)) with a 
VPN server. This means each local client needs client- 
side software and a custom configuration in order to par- 
ticipate in a desired VPN with a remote client or service. 
[0005] As is readily apparent, implementation of con- 
ventional VPN techniques within local networking envi- 
ronments can be challenging and time consuming, since 
each client of the local environment needs to be config- 
ured, maintained, and supported. However, often there 
is little concern with the security of communications being 
compromised within a local and trusted networking en- 
vironment. 

[0006] That is, security concerns are mainly associat- 
ed with specific communications exiting and coming into 
the local networking environment over the insecure net- 
work connection (e.g., Internet). Thus, managing VPN 
techniques at each individual local client or service within 
the local networking environment is excessive and not 
necessary in order to ensure proper security. In other 
words, a single local service could ensure that all local 
clients participating within a VPN distribute and receive 



secure communications over the insecure network with 
desired remote clients or services. In this manner, clients 
or services can participate in a VPN via the service with- 
out having any individual and specific configuration, sup- 

5 port, or maintenance being required. 

[0007] Another drawback to traditional VPN tech- 
niques is that caching of data communicated during a 
VPN session is not available. This means that clients, 
who manage their own VPN session experience slower 

'0 communication rates with their desired remote clients or 
services. Thus, there is a need for accelerating data de- 
livery via local caching to local clients during VPN ses- 
, sions. 

[0008] Thus, improved techniques for transparently 

*5 administering VPNs are needed. 

[0009] WO-02/1 551 4-A (Cyber IQ Systems) describes 
a VPN device clustering system that connects two or 
more VPN devices on one side of a virtual private network 
to a similarly clustered system of two or more VPN de- 

20 vices on the other side of a virtual private network. The 
VPN device clustering system typically includes a plural- 
ity of clustering units for redundancy that avoids difficul- 
ties that arise with a single point of failure. For example 
two clustering units may be used in an active-passive 

25 high-availability configuration. Clients are pre-configured 
to participate in a VPN communication with one another. 
The specific destination address for the target VPN is 
actually unassigned by the client or is associated with a 
generic pool; a proper servicing VPN device is then dy- 

30 namically assigned within the target client's environment. 
Thus, specific assignments of VPN devices are not 
known to clients, but the VPN communications are known 
and pre-configured in the clients. 
[0010] EP-A-1, 304,830 (Stonesoft Corp.) describes 

35 centralized VPN management of a plurality of VPN sites 
by means of a VPN Information Provider (VIP). Manage- 
ment of a VPN device is distributed so that at least part 
of the VPN configuration is centrally managed without 
giving away control of the firewall rulebase or other critical 

40 local configuration used in the VPN device. 

Summary of the Invention 

[0011] The present invention provides methods and 
45 systems for managing a Virtual Private Network (VPN) 
in accordance with claims which follow. In various em- 
bodiments of the invention, techniques are presented for 
transparently administering a VPN. A VPN of this inven- 
tion includes local clients or services, a local transparent 
50 VPN service, a remote transparent VPN service, and re- 
mote clients or services. 

[0012] The local transparent VPN service receives 
communications directed by local clients or services to 
pre- defined ports. These ports are reserved or associ- 
55 ated with VPN communications. When a local client di- 
rects a communication to one of these ports, a switch or 
router relays the communication to the local transparent 
VPN service for processing. The local transparent VPN 
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service inspects the communication for purposes of de- 
termining if the communication can be satisfied from data 
residing in local cache, and if so such data is delivered 
immediately to the initial requesting local client from the 
local cache. 

[001 3] If the communication can not be satisfied from 
the local cache, the n the local transparent VPN service 
identifies the specific VPN and remote client or service 
for which the communication is directed, translates the 
communication and any addresses of the participants 
appropriately and forwards the encrypted communica- 
tion via SSL or TLS to a remote transparent VPN service, 
which performs features similar to the local transparent 
VPN service for the remote client. 

Brief Description of the Drawings 

[0014] 

FIG. 1 is a diagram representing an architectural lay- 
out for a Virtual Private Network (VPN) managing 
system; 

FIG. 2 is a flowchart representing a method for man- 
aging VPN communications; 
FIG. 3 is a flowchart representing another method 
for managing VPN communications; and 
FIG. 4 is a diagram representing a VPN managing 
system. 

Detailed Description of the Invention 

[001 5] As used herein and below a " client" is an elec- 
tronic application, " service", proxy, a computing device, 
or system which may be automated or may be manually 
interacted with by an end-user. 
[0016] The phrases "local networking environment" 
and " external (remote) networking environment are pre- 
sented herein and below. Local networking environment 
refers to physical or logical network devices and services 
which are configured to be local to the clients and which 
interface with the local clients. This does not mean that 
any particular local networking environment of a partic- 
ular local client physically resides in the same geographic 
location of the local client or proximately resides within 
the same geographic location of the local client, although 
in some embodiments this can be the case. Local net- 
working environments can be dispersed geographically 
from the physical location of the local client and form a 
logical local networking environment of the local client. 
An external networking environment is a network which 
is not considered local to the local client. A remote service 
is associated with external or remote networking envi- 
ronments, these external or remote networking environ- 
ments are considered external and remote vis-a-vis a 
local client's networking environment. Moreover, the 
terms local and remote or external are relative terms and 
depending upon who is performing any particular trans- 
action. Thus, a remote client can have a local network 



environment with respect to the remote client. 
[0017] Secure communications refer to communica- 
tions that require specific secure protocols (e.g., SSL, 
TLS, etc.), which are communicated over predefined 
5 ports (e.g., 443, etc.) associated with communication de- 
vices. Secure communications may also refer to any form 
of encryption or custom encryption and agreed upon pro- 
tocol that is used to mutually establish secure communi- 
cations between two or more entities. Thus, in many cas- 
10 es data communication using secure communications re- 
quires encryption. In some instances this encryption uses 
Public and Private Key Infrastructure (PKI) techniques 
and which may also use digital certificates and digital 
signatures. Insecure communications refer to communi- 
15 cations that use insecure protocols (e.g. HTTP, etc.) and 
which use different defined ports (e.g., 80, etc.) of com- 
munication devices from that which are used with secure 
communications. Generally, insecure communications 
will also not include encryption. 
20 [0018] A VPN is a logical network where two or more 
clients or services interact over an insecure network (e.g., 
Internet) in a secure fashion. The secure fashion may 
entail using specific ports (e.g., 443, etc.), using mutually 
agreed upon protocols (e.g., SSL, TLS, custom proto- 
ns cols, etc.), and using mutually agreed upon encryption 
and decryption. Traditionally, a VPN requires each client 
to include configuration, secure protocols, keys, and the 
like which reside on each client participating within a 
VPN. This is not the case with the teachings presented 
30 herein. A local transparent VPN service acts on behalf 
of a plurality of clients within local networking environ- 
ments in order to manage VPN traffic. Remote clients 
and services are interacted with via the VPN through a 
remote transparent VPN service. 
35 [0019] Data acceleration refers to the ability to cache 
data in advance of a need or request for that data. Any 
conventional caching services and managers can be 
used in the caching techniques presented herein and be- 
low with embodiments of this invention. Thus, by way of 
4 ° example, a cache manager can determine when to flush 
certain data from a cache and determine when certain 
data residing within the cache is stale and needs re- 
freshed or updated. Generally, data is accelerated with 
caching techniques because the cache resides closer to 
45 a client and houses needed data in memory which is 
more quickly referenced and accessed. Thus, if a request 
for particular data can be satisfied from a local cache, a 
requesting client experiences a faster response time for 
that data and it appears to the client as if the data has 
50 been accelerated to satisfy a data request. 

[0020] Various embodiments of this invention can be 
implemented in existing network products and services. 
For example, in some embodiments, the techniques pre- 
sented herein are implemented in whole or in part in the 
55 iChain ® , Border Manager ® , and Excelerator ® prod- 
ucts distributed by Novell, Inc., of Provo, Utah. 
[0021] Of course, the embodiments of the invention 
can be implemented in a variety of architectural plat- 



20 



25 



30 



35 



40 



45 



50 



3 



5 



EP 1.583 316, B1 



6 



forms, systems, or applications. For example, portions 
of this invention can be implemented in whole or in part 
in any distributed architecture platform, operating sys- 
tems, proxy services, or browser/ client applications. Any 
particular architectural layout or implementation present- 
ed herein is provided for purposes of illustration and com- 
prehension only and is not intended to limit the various 
aspects of the invention. 

[0022] FIG. 1 is a diagram representing one example 
architectural layout 100 for a Virtual Private Network 
(VPN) managing system. The architecture 100 is imple- 
mented within a distributed client-server architecture. 
The purpose of the architecture 100 is to demonstrate 
how various entities can be configured and arranged for 
interacting and managing a VPN. In some cases, entities 
permit acceleration of data acquired via the VPN. 
[0023] The architecture 1 00 includes one or more local 
clients 101 A-1 01 B, a local transparent VPN service 102, 
a remote transparent VPN service 103, and one or more 
remote clients/ services 1 04A-1 04B. It should me noted 
that the local clients 101 A-1 01 B may also be services. 
The local transparent VPN service 102 communicates 
directly with the remote transparent VPN service 103 
over an insecure network (e.g., Internet) using secure 
communications, such as SSL, TLS, or any other mutu- 
ally agreed upon protocol 110. 
[0024] During operation of the entities within the archi- 
tecture 100, the local clients 101 A-1 01 B are not pre-con- 
figured with VPN capabilities or specialized software for 
processing VPN communications. Instead, the local cli- 
ents 1 01 A-1 01 B attempt to communicate with a specific 
remote client/ service 1 04A or 1 04B or a group of remote 
clients/ services 104A-104B. The local client 101 A or 
101B may or may not know that its communication with 
the desired remote client/ service 104A or 104B is being 
achieved securely via a VPN. For example, a forward or 
transparent proxy may detect local client 101 A or 101 B 
communications and direct those communications to the 
secure port (e.g., 443) associated with VPN traffic. The 
secure communication port is monitored by a router or 
switch (not shown in FIG. 1 ), which detects a destination 
address for a remote client/ service 104A or 104B com- 
munication that is associated with a VPN. This causes 
the router or switch to relay the communication to the 
local transparent VPN service 102. 
[0025] The local transparent VPN service 1 02 inspects 
the intercepted communication and determines whether 
the information or data desired can be satisfied out of a 
local cache, and if so delivers that information or data to 
the local client 101 A or 101B from the local cache. In 
these situations, since the local transparent VPN service 
1 02 acts as a transparent intermediary for the local clients 
1 01 A-1 01 B, the local transparent VPN service 102 is ca- 
pable of communicating with the remote transparent VPN 
service 103 in advance of any specific communication 
from one of the local clients 101 A or 101 B, such that 
data can be pre-acquired and populated in the local 
cache, managed, and accessed by the local transparent 



VPN service 102. 

[0026] Traditionally, VPN communications were not 
capable of being cached within local environments of cli- 
ents, since the secure communications tunnels between 

5 clients prevented any other service acting on behalf of 
the client to cache desired data. However, with the teach- 
ings presented herein, clients 101A-101B and 104A- 
104B can experience accelerated data delivery during 
VPN communications. 

w [0027] If an intercepted VPN communication cannot 
be satisfied by a local cache, the local transparent VPN 
service 1 02 inspects the communication to determine the 
proper VPN being requested based on the addresses of 
the participants (e.g., local and remote clients or services 

15 1 01 A- 101 B and 104A- 104B). This permits the local 
transparent VPN service 1 02 to identify a needed remote 
transparent VPN service 103 with which the local trans- 
parent VPN service 102 communicates. 
[0028] Next, the local transparent VPN service 102 

20 performs the needed encryption on the communication 
and optionally on the addresses of the participants. The 
encryption is based on the identified VPN associated with 
the participants and their addresses. The encrypted com- 
munication is then sent over the insecure network (e.g., 

25 internet) using a secure communications protocol (e.g., 
SSL, TLS, any mutually agreed upon protocol, etc.). 
[0029] The encrypted communication is detected on a 
secure port (e.g., 443) within the remote networking en- 
vironment and, in manners similar to what was discussed 

30 above, is forwarded to the remote transparent VPN serv- 
ice 103. The remote transparent VPN service 103 de- 
crypts the communication and addresses, if applicable, 
and forwards the communication to needed remote cli- 
ents/ services 104 A- 104B for processing. 

35 [0030] The targeted remote client/ service 104A or 
104B acts on the communication and generates a re- 
sponse which it directs to the local client 101 A or 101 B. 
This response is intercepted and directed to the remote 
secure communication port. There, the reply is intercept- 

4 o ed again and relayed to the remote transparent VPN serv- 
ice 1 03, where it is encrypted and sent from the remote 
transparent VPN service 103 over the insecure network 
using a secure communications protocol (SSL or TLS 
1 1 0) to the local transparent VPN service 1 02. The local 

45 transparent VPN service 102 can cache the response 
and its data within a local cache and delivers the re- 
sponse to the original requesting local client 101 A or 
101B. 

[0031] The local transparent VPN service 1 02 and the 
50 remote transparent VPN service 103 communicate di- 
rectly with one another over an insecure network using 
secure communications (e.g., protocols and/ or encryp- 
tion and decryption). Each transparent VPN service 102 
or 1 03 can service a plurality of clients or services 1 01 A- 
55 101 B and 1 04A- 1 04B which engage in VPN interactions. 
Thus, individual clients/ services 101 A- 101B or 104A- 
104B need not be pre-configured, managed, and sup- 
ported for VPN communications and still can benefit and 
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participate in VPNs with the teachings presented herein. 
Additionally, the clients/ services 101A-101B and 104A- 
1 04B can, with some embodiments, experience acceler- 
ated data deliver during a VPN session, since the trans- 
parent VPN services 102 or 103 can cache data in ad- 
vance of a need to satisfy a received communication. 
[0032] FIG. 2 is a flowchart of one method 200 for man- 
aging VPN communications. The method 200 is imple- 
mented in a computer readable medium and is accessi- 
ble over a network. In one embodiment, the method 200 
is implemented as a local transparent VPN service, which 
is designed to interact with one or more local clients or 
services and designed to securely interact with a remote 
transparent VPN over an insecure network. The remote 
transparent VPN service is another processing instance 
of the method 200, which resides and processes in an 
external or remote networking environment. The 
processing of the method 200 is referred to as a " local 
transparent VPN service" herein and below. 
[0033] In one embodiment, the transparent VPN serv- 
ice is a service which the local clients or services are not 
aware of That is, local clients are not pre-configured to 
directly interact with the local transparent VPN service. 
In this situation a router, switch, or proxy can be used to 
forward communications from the local clients to the local 
transparent VPN service. In a different embodiment, the 
local clients are configured to directly send VPN commu- 
nications to the local transparent VPN service. 
[0034] A local client or service issues a communication 
request for a remote client of service. This communica- 
tion is directed or redirected on behalf of the local client 
to a specific secure communications port (e.g., 443, etc.), 
where a router or switch relays or forwards the commu- 
nication to the local transparent VPN service. According- 
ly, at 210, the local transparent VPN service receives a 
communication from a local client, which is directed to a 
remote client or service. Further, at 21 1, this communi- 
cation is detected, in some embodiments, based on the 
local client's attempt to access a defined port with the 
communication. 

[0035] The communications can also be based on the 
type of communication taking place. For example, in 
some embodiments, maybe only File Transfer Protocol 
(FTP) or Transmission Control Protocol (TCP) commu- 
nication types are inspected and processed by the local 
transparent VPN service. Accordingly, processing can 
be based on the use of a specific communication port, 
based on a specific type of communication (e.g., FTP, 
TCP, etc.), or based on a combination of a specific com- 
munication port and a specific type of communication. 
[0036] At 220, the local transparent VPN service re- 
ceives the communication and identifies the VPN asso- 
ciated with the communication. To do this, the local trans- 
parent VPN service inspects the address or identity of 
the local client and the address or identity of the remote 
client or service. This information is looked up in a table 
or other data structure to acquire the identity of the spe- 
cific VPN used between the local client and the remote 



client or service. 

[0037] Once the specific VPN is identified, the local 
transparent VPN service can acquire the encryption, key, 
and any certificate information necessary to interact with 
5 a remote transparent VPN service at 221. The remote 
transparent VPN service is a remote processing instance 
of the local transparent VPN service. That is, the remote 
transparent VPN service is a local transparent VPN serv- 
ice with respect to the remote client or service. 
[0038] In some embodiments, at 222, the original re- 
ceived communication is inspected by the local transpar- 
ent VPN service for purposes of determining whether it 
can be satisfied from a local cache. In this way, the local 
transparent VPN service and the remote transparent 
VPN service interact with one another in advance and at 
different times than what may be requested by a local 
client and a remote client or service. 
[0039] During these interactions, the local transparent 
VPN service acquires data associated with the remote 
client or service from the remote transparent VPN service 
and houses that data in a local cache that resides within 
the local networking environment of the local client and 
the local transparent VPN service. Thus, when the local 
client issues a communication request, the local trans- 
parent VPN service can inspect the local cache to deter- 
mine if that communication can be satisfied locally. By 
doing this, the local client experiences accelerated data 
delivery during a VPN managed transaction. Convention- 
ally, this has not been achievable. 
[0040] In a like manner the remote transparent VPN 
service can acquire data from the local client via the local 
transparent VPN service and cache that data in a remote 
cache (local cache vis- a- vis the remote client or service 
and remote transparent VPN service), where that data 
can be used to accelerate data delivery to the remote 
client or service which interacts via the VPN with the local 
client. 

[0041] At 230, the local transparent VPN service trans- 
lates the original received communication and, optional- 
ly, any addresses of the parties involved (e.g., local and 
remote clients or services) into encrypted formats re- 
quired by the VPN. That encrypted information is then 
sent using secure communications (e.g., protocols 
and/or encryption and decryption) to the remote trans- 
parent VPN service. The remote transparent VPN service 
receives that encrypted communication, decrypts it, iden- 
tifies the address of the desired remote client or service, 
and forwards the decrypted version locally to that remote 
client or service. The remote client or service responds 
via a defined secure communication port (either directly 
or indirectly) within the remote networking environment. 
That response is relayed to the remote transparent VPN 
service, where it is translated and sent with secure com- 
munications to the local transparent VPN service. 
[0042] Interactions between the local and remote 
transparent VPN services occur as long as the local and 
remote clients or services are interacting via the identified 
VPN. The transparent VPN services acts as intermedi- 
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aries for the local and remote clients or services. A single 
transparent VPN service can service a plurality of clients 
or services which are within the local networking envi- 
ronment of that transparent VPN service. 
[0043] Conventionally, a VPN transaction required 
each client or service to be specifically configured, main- 
tained, and supported for purposes of participating in 
VPN communications. With the teachings of this inven- 
tion, this is no longer required since all clients or services 
of one environment can participate in a variety of VPN- 
defined communications with all clients or services of a 
different environment and all that is needed is a single 
transparent VPN service, which has an operational in- 
stance processing in each environment. Thus, two serv- 
ices can achieve what has previously required modifica- 
tion to all clients and services participating in VPN- de- 
fined communications. 

[0044] In fact, in some embodiments, the local and re- 
mote clients are not even aware of the secure commu- 
nications and the VPN being used in between their com- 
munications with one another. Thus, as far as the clients 
are concerned they believe that they are communicating 
insecurely with one another, when in fact communication 
between them is occurring via a VPN over a public or 
otherwise insecure network via the transparent VPN 
services. 

[0045] FIG. 3 is a flowchart of another method 300 for 
managing VPN communications. The method is imple- 
mented in a computer readable medium and is accessi- 
ble over any network or combination of networks. Similar, 
to the method 200 of FIG. 2 above, the method 300 can 
be viewed as a local transparent VPN service that inter- 
acts with another processing instance of itself (defined 
as a remote transparent VPN service) over a network. 
The two processing instances of the transparent VPN 
services manage VPN communications for a plurality of 
clients and services. 

[0046] At 310, the local transparent VPN service re- 
ceives an intercepted local client communication (can 
also be a local service). The communication is intercept- 
ed by detecting it on a predefined port which is monitored 
or listened to by the local transparent VPN service or 
which is monitored by a router or switch that automatically 
forwards communications to the local transparent VPN 
service. 

[0047] The local transparent VPN service can be used 
to manage additional communications associated with a 
plurality of different local clients, as depicted at 321 . That 
is, the local transparent VPN service intercepts and man- 
ages VPN communications for local clients or services 
which are within the local networking environment of the 
local transparent VPN service. 

[0048] At 320, the intercepted communication from the 
local client is relayed and received for processing by the 
local transparent VPN service. At 330, that communica- 
tion is inspect to determine if it can be satisfied from local 
cache being managed and maintained by the local trans- 
parent VPN service. 



[0049] The local transparent VPN service interacts 
with its counterpart, the remote transparent VPN service, 
using secure communications (e.g., protocols (SSL, TLS, 
etc.) and/ or encryption and decryption). Thus, the local 

5 transparent VPN service can pre- acquire data from one 
or more remote clients or services via the remote trans- 
parent VPN service. Similarly, the remote transparent 
VPN service can reacquire data from one of more local 
clients of services via the local remote transparent VPN 

10 service. The data is stored and managed in caches, one 
cache local to the local client and another cache local to 
the remote client or service. 

[0050] If at 330, the received communication can be 
satisfied from the cache, then, at 331, the local client is 
15 serviced with data from the local cache. In this manner, 
the local client can, in some instances, experience ac- 
celerated data delivery associated with VPN interactions. 
This has not conventionally been achievable. However, 
if at 330, the received communication cannot be satisfied 
20 from the local cache then, at 340, the proper remote 
transparent VPN service is located. The local transparent 
VPN service can interact with a plurality of remote trans- 
parent VPN services, so, at 340, the identity of the need- 
ed remote transparent VPN service is acquired based on 
25 the remote client or service for which the original com- 
munication is being directed. 

[0051] The local transparent VPN service and the re- 
mote transparent VPN service interact with one another 
via secure communications, such as SSL or TLS. In some 
30 instances for added security digital certificates can be 
exchanged and in some instances the communications 
or certificates can be mutually or unilaterally digitally 
signed, as depicted at 341. 

[0052] Once the identity of the remote transparent VPN 
35 service is known, the communication is translated (e.g., 
encrypted) and sent via the proper VPN to the target re- 
mote transparent VPN service, at 342. The translated 
communication is sent via secure communications (e.g., 
SSL or TLS). Once the encrypted communication is re- 
40 ceived by the remote transparent VPN service, it is de- 
crypted and sent to the proper remote client or service 
for processing. 

[0053] Once processed, the remote transparent VPN 
service intercepts the remote client's or service's re- 
^5 sponse, encrypts it and sends it securely via the VPN 
using secure communications to the local transparent 
VPN service. The local transparent VPN service, de- 
crypts it, optionally caches the data associated with it in 
local cache, and delivers it to the originally requesting 
50 local client. 

[0054] The transparent VPN services act as VPN in- 
termediaries or managers for VPN communications. This 
permits data during VPN communications to be cached 
and accelerated for deliver to clients or service and per- 
55 mits a plurality of clients or services to actively and ben- 
eficially participate in VPN communications without re- 
quiring individual maintenance, support, and configura- 
tion to achieve the same. 
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[0055] FIG. 4 is a diagram depicting a VPN managing 
system 400. The VPN managing system 400 is imple- 
mented in a computer readable or accessible medium 
and is accessible over any network or combination of 
networks. In some embodiments, portions of the VPN 
managing system 400 can be implemented using the 
techniques presented above with respect to method 200 
or method 300 of FIGS 2- 3. 

[0056] The VPN managing system 400 includes a local 
transparent VPN service 401 and a remote transparent 
VPN service 402. In another embodiment, the VPN man- 
aging system 400 includes a local transparent VPN serv- 
ice 401 and a local communication port 401 A. 
[0057] The VPN managing system 400 is operational 
in a local client environment and a remote client or service 
environment. Each separate environment can include 
one or more identical entities. For example, the local cli- 
ent environment can include local communication ports 
401 A, local routers or switches 401 B, and local cache 
401 C. At the same time, the remote client or service en- 
vironment can include remote ports 402A, remote routers 
or switches 402B, and remote cache 402. In some em- 
bodiments, one or more entities may be omitted. Addi- 
tionally, the environments need not be identically repli- 
cated, as is depicted in FIG. 4 for purposes of illustration. 
[0058] The local client environment includes a plurality 
of clients or services 410. Each of these clients or serv- 
ices 410 can participate in VPN communications over an 
insecure network 415 with a plurality of remote clients or 
services 420, which reside in the remote client or service 
environment. The local and remote clients or services 
410 and 420 do not need to be specifically configured to 
participate in VPN communications; rather, the details of 
VPN communications are managed by the two transpar- 
ent VPN services 401 and 402. Each of the transparent 
VPN services 401 and 402 are capable of multiplexing, 
encrypting, or decrypting communications occurring be- 
tween them and sending communications securely via 
SSL or TLS for purposes of effectuating a desired VPN. 
In fact, in many instances, the clients may be entirely 
unaware that they are communicating securely with other 
remote clients or services 420. 

[0059] A local client 41 0 issues a communication to a 
specific secure communications port 401A. This can be 
achieved directly (e.g., forward proxy not shown in FIG. 
4) or indirectly (e.g., transparent proxy not shown in FIG. 
4). The local transparent VPN service 401 listens on that 
port for VPN activity. Alternatively, a local router or switch 
401 B detects the activity and based on its type (e.g., 
FTP, TCP, etc.) or based on where it is headed (e.g., 
target remote client or service 420) relays or forwards 
the activity to the local transparent VPN service 401. 
[0060] Once the local transparent VPN service 401 re- 
ceives a communication associated with a VPN from a 
local client or service 410 which is destined for a remote 
client of service 420 over the insecure network 415, the 
local transparent VPN service 401 determines the iden- 
tity of the remote transparent VPN service 402 with which 



it needs to interact over the desired VPN. Once this is 
known, the encrypting, decryption, certificate, keys, or 
multiplexing requirements can be established and the 
communication can be translated and sent over the in- 

5 secure network 41 5 using secure communications (e.g., 
protocols and/ or encryption and decryption). 
[0061] In some embodiments, the communication can 
be inspected by the local transparent VPN service 401 
for purposes of determining whether it can be satisfied 

w from contents of existing local cache 401 C, and if it can 
be so satisfied, the local client's 410 original communi- 
cation is immediately responded to with data residing in 
the local cache 401 C. Thus, in some embodiments, client 
or service 410 and 420 can experience accelerated re- 

15 sponse time and data delivery, because of the caching 
abilities of the transparent VPN services 401 and 402. 
The caching is not limited to the local client environment, 
since, in some embodiments, the remote transparent 
VPN service 402 can perform caching using its remote 

20 cache 402C on behalf of its remote clients of services 
420. 

[0062] If a communication cannot be satisfied from 
cache 401 C or 402C, then the appropriate transparent 
VPN service 401 or 402 encrypts and securely transmits 
25 the encrypted communication over the insecure network 
to its counterpart transparent VPN service 401 or 402. 
Here, the encrypted communication is decrypted or mul- 
tiplexed and forwarded to the appropriate client or service 
410 or 420 for processing and reply. The reply is then 
30 processed in the same manner as the communication 
was processed. 

[0063] In some embodiments, the transparent VPN 
services 401 and 402 can interact with digital certificates 
and/ or via digital signatures. In fact, the desired level of 
35 security can be configured based on the needs of an 
organization. The services 401 and 402 interact with one 
another for purposes of achieving VPN communications 
on behalf of clients or services 410 and 420 of their en- 
vironments. Moreover, in some instances, data is cached 
40 and provided for accelerated delivery. These benefits 
have not been achievable with conventional VPN tech- 
niques. 

[0064] Although specific embodiments have been il- 
lustrated and described herein, those of ordinary skill in 
45 the art will appreciate that any arrangement calculated 
to achieve the same purpose can be substituted for the 
specific embodiments shown. This disclosure is intended 
to cover all adaptations or variations of various embodi- 
ments of the invention. It is to be understood that the 
50 above description has been made in an illustrative fash- 
ion only. Combinations of the above embodiments, and 
other embodiments not specifically described herein will 
be apparent to one of ordinary skill in the art upon re- 
viewing the above description. The scope of various em- 
55 bodiments of the invention includes any other applica- 
tions in which the above structures and methods are 
used. 
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Claims 

1 . A computer-implemented method for managing Vir- 
tual Private Network (VPN) communications, com- 
prising: 

receiving (2 1 0), at a local transparent VPN serv- 
ice (401), a communication from a local client 
(410) which is directed to a remote client (420) 
over an insecure network (415); 
identifying (220) a VPN associated with the com- 
munication; 

translating (230) the communication into an en- 
crypted format for delivery within the VPN; 
sending (231) the translated communication 
from the local transparent VPN service (401 ) via 
the VPN to a remote transparent VPN service 
(402), which manages VPN traffic for the remote 
client by decrypting and supplying the translated 
communication to the remote client; 
characterized in that neither the local client 
(410) nor the remote client (420) is preconfig- 
ured with VPN capabilities or specialized soft- 
ware for processing VPN communications, and 
in that said receiving (210) comprises the steps 
of; 

detecting, at a forward or transparent proxy, 
router or switch (401 B) the communication from 
the local client whenever the local client at- 
tempts to send the communication insecurely 
over a network to the remote client via a specific 
predefined communications port (401 A); 
intercepting the detected communication and di- 
recting (21 1 ) it from the proxy, router or switch 
to the local transparent VPN service. 

2. The method of claim 1 further comprising, interacting 

(221 ) with the remote transparent VPN service (402) 
to manage additional communications between the 
local client and the remote client via the VPN. 

3. The method of claim 2 further comprising, caching 

(222) data received from the remote transparent 
VPN service (402) in a local cache for accelerated 
delivery to the local client (410). 

4. The method of claim 1 wherein receiving (210) the 
communication further includes receiving the com- 
munication in at least one of a File Transfer Protocol 
(FTP) format and a Transmission Control Protocol 
(TCP) format. 

5. The method of claim 1 further comprising, commu- 
nicating with the remote transparent VPN service 
(402) over the insecure network (415) via Secure 
Sockets Layer (SSL) or Transport Layer Security 
(TLS). 



6. The method of claim 1 , further comprising: 

inspecting (330) the communication for deter- 
mining whether the communication is a request 

5 for data that resides in a local cache (401 C), and 

if so, delivering (331) the data to the local client 
(410), and if not, locating (340) a remote trans- 
parent VPN service (402) associated with the 
VPN, and wherein the communication is trans- 

10 lated (342) into formats used by the VPN and 

sent securely over an insecure network to the 
remote transparent VPN service for delivery 
(343) to the remote client (420). 

15 7. The method of claim 6 wherein inspecting (330) fur- 
ther includes establishing (341 ) secure communica- 
tions with the remote transparent VPN service (402) 
using at least one of Sockets Layer (SSL) and Trans- 
port Layer Security (TLS). 

20 

8. The method of claim 6 wherein inspecting (330) fur- 
ther includes identifying the remote transparent VPN 
service (402) as a service which is managing VPN 
traffic for the remote client (420). 

25 

9. The method of claim 6 further comprising: 

receiving a response communication from the 
remote client (420) via the remote transparent 
30 VPN service (402), if the communication had 

been sent via the VPN because it could not be 
satisfied from the local cache (401 C); 
translating the response based on the formats 
of the VPN; and 
35 delivering the translated response to the local 

client. 

10. The method of claim 6 further comprising, managing 
(321 ) additional communications associated with the 

40 VPN from one or more different local clients (410) 
which are directed between one or more different 
remote clients (420), wherein the remote transparent 
VPN service (402) manages the additional commu- 
nications on behalf of the one or more different re- 
45 mote clients. 

11. The method of claim 6 wherein receiving further in- 
cludes intercepting (310) the communication after 
detecting that the local client is transmitting the com- 

50 munication with a non-Hypertext Transfer Protocol 
(HTTP). 

12. The method of claim 6 further comprising, interacting 
(341 ) with the remote transparent VPN service with 

55 mutually signed certificates that are exchanged be- 
tween the local and the remote transparent VPN 
services during the interactions. 
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13. A Virtual Private Network (VPN) managing system 
(400), wherein neither local client(s) (410) nor re- 
mote client(s) (420) is/are preconfigured with VPN 
capabilities or specialized software for processing 
VPN communications, comprising: 

a local transparent VPN service (401); 
a local forward or transparent proxy, router or 
switch (401 B), adapted for detecting a commu- 
nication from a local client whenever the local 
client attempts to send the communication inse- 
curely over a network to a remote client via a 
specific predefined local communications port 
(401 A), and adapted to intercept the detected 
communication and to direct (211) it from the 
local proxy, router or switch to the local trans- 
parent VPN service; 

a remote transparent VPN service (402); 
a remote forward or transparent proxy, router or 
switch (402B), adapted for detecting a commu- 
nication from a remote client whenever the re- 
mote client attempts to send the communication 
insecurely over the network to a local client via 
a specific predefined remote communications 
port (402A), and adapted to intercept the detect- 
ed communication and to direct (21 1 ) it from the 
remote proxy, router or switch to the remote 
transparent VPN service. 

14. The VPN managing system of claim 13, further com- 
prising 

a local cache (401 C); 

wherein local transparent VPN service (401) inter- 
cepts and manages VPN traffic on behalf of one or 
more local clients (410) and services communica- 
tions of those local clients with data in the local cache 
(401 C), if available, and if the data is not available 
in the local cache, the local transparent VPN service 
transmits the communications securely to the re- 
mote transparent VPN service for delivery and serv- 
icing by one or more remote clients (420) which the 
remote transparent VPN service (402) manages. 

15. The VPN managing system of claim 13 wherein the 
local transparent VPN service (401 ) and the remote 
transparent VPN service (402) interact via at least 
one of Secure Sockets Layer (SSL) and Transport 
Layer Security (TLS). 

16. The VPN managing system of claim 1 3 wherein the 
local transparent VPN service (102,401) intercepts 
local VPN traffic on behalf of the one or more local 
clients (1 01 ,410) by inspecting Transmission Control 
Protocol (TCP) or File Transfer Protocol (FTP) com- 
munications originating from the one or more local 
clients. 



17. The VPN managing system of claim 1 3 wherein com- 
munications between the local (1 02,401 ) and remote 
(1 03,402) transparent VPN services occur with mu- 
tually exchanged certificates. 

5 

18. The VPN managing system of claim 13, wherein the 
system resides on a server and services a plurality 
of local clients (410) associated with the VPN com- 
munications. 

10 

19. The VPN managing system of claim 13 wherein the 
system resides on a single client. 

20. A computer program which when executing on a 
15 computer or computer network performs the method 

as claimed in any one of claims 1 to 1 2. 

21. The computer program of claim 20, when stored on 
a machine-accessible medium. 



Patentanspruche 

1. Computer-implementiertes Verfahren zum Organi- 
25 sieren von Kommunikationen eines virtuellen Privat- 
netzes (VPN), umfassend: 

Empfangen (210) einer Kommunikation von ei- 
nem lokalen Client (410), die zu einem fernen 
30 Client (420) gerichtet ist, uber ein unsicheres 

Netz (415) bei einem lokalen transparenten 
VPN-Dienst (401); 

Identifizieren (220) eines der Kommunikation 
zugeordneten VPN; 
35 Ubersetzen (230) der Kommunikation in ein ver- 

schliisseltes Format zur Lieferung innerhalb des 
VPN; 

Senden (231) der ubersetzten Kommunikation 
von dem lokalen transparenten VPN-Dienst 
*o (401) uber das VPN zu einem fernen transpa- 

renten VPN-Dienst (402), der den VPN-Verkehr 
fur den fernen Client organisiert durch Ent- 
schlusseln und Zufuhren der ubersetzten Kom- 
munikation zu dem fernen Client; 
^5 dadurch gekennzeichnet, dass weder der lo- 

kale Client (41 0) noch der feme Client (420) mit 
VPN-Fahigkeiten oder spezialisierter Software 
zum Verarbeiten von VPN-Kommunikationen 
vorkonfiguriert ist, und dass das Empfangen 
50 (210) die Schritte umfasst; 

Erfassen der Kommunikation von dem lokalen 
Client bei einem Weiterleitungs- oder Transpa- 
rent-Proxy, Router oder einer entsprechenden 
Vermittlung (401 B) jedes Mai, wenn der lokale 
55 Client versucht, Kommunikation in unsicherer 

Weise uber ein Netz zu dem fernen Client uber 
einen spezifizierten vordefinierten Kommunika- 
tionsanschluss (401A) zu senden; 
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8. Verfahren nach Anspruch 6, wobei das Inspizieren 
(330) ferner das Identifizieren des fernen transpa- 
renten VPN-Dienstes (402) als einen Dienst ein- 
schliefit, der VPN-Verkehr fur den fernen Client 

5 (420) organisiert. 

9. Verfahren nach Anspruch 6, ferner umfassend: 

Empfangen einer Antwort-Kommunikation von 
10 dem fernen Client (420) uber den fernen trans- 

parenten VPN-Dienst (402), wenn die Kommu- 
nikation uber das VPN gesendet worden ist, weil 
es von dem lokalen Cash (401 C) nicht zufrie- 
dengestellt werden konnte; 
15 Ubersetzen der Antwort basierend auf den For- 

maten des VPN; und 

Liefern der ubersetzten Antwort an den lokalen 
Client. 

20 10. Verfahren nach Anspruch 6, ferner das Organisieren 
(321) zusatzlicher, zwischen einem Oder mehreren 
unterschiedlichen fernen Clients (420) gerichteter 
Kommunikationen, die dem VPN zugeordnet sind, 
von einem oder mehreren unterschiedlichen lokalen 

25 Clients (410) umfassend, wobei der feme transpa- 
rente VPN-Dienst (402) die zusatzlichen Kommuni- 
kationen anstelle des einen oder der mehreren un- 
terschiedlichen fernen Clients organisiert. 

30 11. Verfahren nach Anspruch 6, wobei das Empfangen 
ferner das Abfangen (310) der Kommunikation ein- 
schliefit nach dem Erfassen, dass der lokale Client 
die Kommunikation nicht mit einem Hypertext- 
Transfer-Protocol (HTTP) sendet. 

35 

12. Verfahren nach Anspruch 6, ferner das Interagieren 
(341 ) mit dem fernen transparenten VPN-Dienst mit 
gegenseitig signierten Zertifikaten umfassend, die 
zwischen den lokalen und den fernen transparenten 
40 VPN-Diensten wahrend der Interaktionen ausge- 
tauscht werden. 



Abfangen der erfassten Kommunikation und 
Richten (211) von ihr von dem Proxy, Router 
oder der Vermittlung zu dem lokalen transpa- 
renten VPN-Dienst. 

2. Verfahren nach Anspruch 1 , ferner das Interagieren 
(221) mit dem fernen transparenten VPN-Dienst 
(402) umfassend zum Organisieren zusatzlicher 
Kommunikationen zwischen dem lokalen Client und 
dem fernen Client uber das VPN. 

3. Verfahren nach Anspruch 2, ferner das Zwischen- 
speichern (222) von von dem fernen transparenten 
VPN-Dienst (402) empfangenen Daten in einem lo- 
kalen Cash- bzw. Zwischenspeicher zum beschleu- 
nigten Liefern zu dem lokalen Client (410) umfas- 
send. 

4. Verfahren nach Anspruch 1 , wobei das Empfangen 
(210) der Kommunikation ferner das Empfangen der 
Kommunikation in mindestens einem von einem Da- 
teienubertragungsprotokoll- bzw. File-Transfer-Pro- 
tocol-Format (FTP-Format) und einem Sendesteu- 
erprotokoll- bzw. Transmission-Control-Protocol- 
Format bzw. (TCP-Format) einschlieftt. 

5. Verfahren nach Anspruch 1 , ferner das Kommuni- 
zieren mit dem fernen transparenten VPN-Dienst 
(402) uber das unsichere Netz (415) uber die SSL- 
Schicht bzw. Secure-Sockets-Layer oder TLS bzw. 
Transportschichtsicherheit (TLS) umfassend. 

6. Verfahren nach Anspruch 1 , ferner umfassend: 

Inspizieren (330) der Kommunikation in Bezug 
auf das Bestimmen, ob die Kommunikation eine 
Abfrage fur Daten ist, die sich in einem lokalen 
Cash-Speicher befinden (401 C), und wenn das 
der Fall ist, Liefern (331) der Daten zu dem lo- 
kalen Client (410), und wenn es nicht der Fall 
ist, Lokalisieren (340) eines fernen transparen- 
ten VPN-Dienstes (402), der dem VPN zugeord- 
net ist, und 

wobei die Kommunikation in Formate ubersetzt wird 
(342), die durch das VPN verwendet werden, und 
sicher uber ein unsicheres Netzzu dem fernen trans- 
parenten VPN-Dienst gesendet werden zur Liefe- 
rung (343) an den fernen Client (420). 

7. Verfahren nach Anspruch 6, wobei das Inspizieren 
(330) ferner das Einrichten (341) sicherer Kommu- 
nikationen mit dem fernen transparenten VPN- 
Dienst (402) unter Verwendung von mindestens ei- 
nem von SSL bzw. Secure-Sockets-Layer (SSL) und 
TLS bzw. Transport-Layer-Security (TLS) ein- 
schliefit. 



13. Organisationssystem (400) eines virtuellen Privat- 
netzes (VPN), wobei weder ein oder mehrere lokale 
45 Clients (410) noch ein oder mehrere feme Clients 
(420) mit VPN-Fahigkeiten oder spezialisierter Soft- 
ware zum Verarbeiten von VPN-Kommunikationen 
vorkonfiguriert sind, umfassend: 

50 einen lokalen transparenten VPN-Dienst (401 ); 

einen lokalen Weiterleitungs- oder Transparent- 
Proxy, Router oder eine entsprechende Vermitt- 
lung (401 B), angepasst zum Erfassen einer 
Kommunikation von einem lokalen Client jedes 
55 Mai wenn der lokale Client versucht, die Kom- 

munikation unsicher uber ein Netz zu einem fer- 
nen Client uber einen spezifisch vordefinierten 
lokalen Kommunikationsanschluss (401A) zu 
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senden, und angepasst zum Abfangen der er- 
fassten Kommunikation und zum Richten (211) 
von ihr von dem lokalen Proxy, Router Oder der 
Vermittlung zu dem lokalen transparenten VPN- 
Dienst; 

einen fernen transparenten VPN-Dienst (402); 
einen fernen Weiterleitungs- oder Transparent- 
Proxy, Router oder eine entsprechende Vermitt- 
lung (402B), angepasst zum Erfassen einer 
Kommunikation von einem fernen Client jedes 
Mai, wenn der feme Client versucht, die Kom- 
munikation unsicher uber das Netz zu einem lo- 
kalen Client uber einen spezifischen vordefinier- 
ten fernen Kommunikationsanschluss (402A) 
zu senden, und angepasst zum Abfangen der 
erfassten Kommunikation und zum Richten 
(211) von ihr von dem fernen Proxy, Router oder 
der Vermittlung zu dem fernen transparenten 
VPN-Dienst. 

14. VPN-Organisationssystem nach Anspruch 13, fer- 
ner einen lokalen Zwischenspeicher bzw. Cash 
(401 C) umfassend; 

wobei der lokale transparente VPN-Dienst (401) 
VPN-Verkehr fur einen oder mehrere lokale Clients 
(410) und Dienstekommunikationen von jenen loka- 
len Clients mit Daten im lokalen Cash-Speicher 
(401 C) wenn verfugbar abfangt und organisiert, und 
wenn die Daten nicht in dem lokalen Cash-Speicher 
verfugbar sind, der lokale transparente VPN-Dienst 
die Kommunikationen sicher zu dem fernen trans- 
parenten VPN-Dienst ubermittelt zum Liefern und 
Bedienen durch einen oder mehrere feme Clients 
(420), der bzw. die den fernen transparenten VPN- 
Dienst (402) organisiert bzw. organisieren. 

15. VPN-Organisationssystem nach Anspruch 13, wo- 
bei der lokale transparente VPN-Dienst (401) und 
der feme transparente VPN-Dienst (402) uber min- 
destens eines von Secure-Sockets-Layer (SSL) und 
Transport-Layer-Security (TLS) interagieren. 

16. VPN-Organisationssystem nach Anspruch 13, wo- 
bei der lokale transparente VPN-Dienst (102, 401) 
lokalen VPN-Verkehr fur den einen oder die mehre- 
ren lokalen Clients (101, 410) abfangt durch Inspi- 
zieren von Kommunikationen, die von einem oder 
mehreren lokalen Clients stammen, unter Verwen- 
dung des Sendesteuerungsprorokolls bzw. Trans- 
mission-Control-Protocol (TCP) oder des Dateiiiber- 
tragungsprotokolls bzw. File-Transfer-Protocol 
(FTP). 

17. VPN-Organisationssystem nach Anspruch 13, wo- 
bei die Kommunikationen zwischen den lokalen 
(1 02, 401 ) und den fernen (1 03, 402) transparenten 
VPN-Diensten mit gegenseitig ausgetauschten Zer- 
tiflkaten auftreten. 



18. VPN-Organisationssystem nach Anspruch 13, wo- 
bei das System sich auf einem Server befindet und 
eine Vielzah! lokaler Clients (410) bedient, die den 
VPN-Kommunikationen zugeordnet sind. 

5 

19. VPN-Organisationssystem nach Anspruch 13, wo- 
bei sich das System auf einem einzelnen Client be- 
findet. 

10 20. Computerprogramm, das wenn es auf einem Com- 
puter oder in einem Computernetz ausgefuhrt wird, 
das Verfahren durchfuhrt, wie es in einem der An- 
spruche 1 bis 12 beansprucht wird. 

15 21. Computerprogramm nach Anspruch 20, wenn auf 
einem Maschinen-zugreifbaren Medium gespei- 
chert. 



20 Revendications 

1. Procede implements par ordinateur pour gerer des 
communications de reseau prive virtuel (VPN), com- 
portant les etapes suivantes : 
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recevoir (210), au niveau d'un service VPN 
transparent local (401 ), une communication pro- 
venantd'un client local (410)quiestdirigee vers 
un client eloigne (420) sur un reseau non secu- 
rise (415); 

identifier (220) un VPN associe a la 
communication ; 

transformer (230) la communication en un for- 
mat crypte pour livraison dans le VPN ; 
envoyer (231 ) la communication transformee du 
service VPN transparent local (401 ) via le VPN 
vers un service VPN transparent eloigne (402), 
qui gere le trafic VPN pour le client eloigne en 
dechiffrant et en fournissant la communication 
transformee au client eloigne ; 
caracterise en ce que ni le client local (410) ni 
le client eloigne (420) n'est preconfigure avec 
des capacites VPN ou un logiciel specialise pour 
traiter des communications VPN, et en ce que 
ladite reception (210) comporte les etapes 
suivantes : 

detecter, au niveau d'un proxy de transfert ou 
transparent, d'un routeur ou d'un commutateur 
(401 B), la communication du client, local a cha- 
que fois que le client local essaye d'envoyer la 
communication de maniere non securisee sur 
un reseau au client eloigne via un port de com- 
munications predefini specifique (401A) ; 
intercepter la communication detectee et la di- 
nger (211) du proxy, routeur ou commutateur 
vers le service VPN transparent local. 

2. Procede selon la revendication 1, comportant en 
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outre une interaction (221) avec le service VPN 
transparent eloigne (402) pour gerer des communi- 
cations supplementaires entre le client local et le 
client eloigne via le VPN. 

3. Procede selon la revendication. 2 comportant en 
outre I'etape de cacher (222) des donnees recues 
du service VPN transparent eloigne (402) dans un 
cache local pour une livraison acceleree au client 
local (410). 

4. Procede selon la revendication 1 , dans lequel la re- 
ception (210) de la communication comporte en 
outre la reception de la communication dans au 
moins un format parmi un format, de protocole de 
transfert de fichiers (FTP) et un format de protocole 
de commande de transmission (TCP). 

5. Procede selon la revendication 1, comportant en 
outre une communication avec le service VPN trans- 
parent eloigne (402) sur le reseau non securise (41 5) 
via un protocole SSL (Secure Sockets Layer) ou un 
protocole TLS (Transport Layer Security). 

6. Procede selon la revendication 1, comportant en 
outre les etapes suivantes : 

examiner (330) la communication pour determi- 
ner si la communication est une requete de don- 
nees qui resident dans un cache local (401 C), 
et si c'est le cas, delivrer (331) les donnees au 
client local (410), et sinon, localiser (340) un ser- 
vice VPN transparent eloigne (402) associe au 
VPN, et dans lequel la communication est trans- 
former (342) en des formats utilises par le VPN, 
et envoyes de maniere securisee sur un reseau 
non securise vers le service VPN transparent 
eloigne pour livraison (343) au client eloigne 
(420). 

7. Procede selon la revendication 6, dans lequel I'exa- 
men (330) comporte en outre I'etablissement (341) 
de communications securisees avec le service VPN 
transparent, eloigne (402) en utilisant au moins un 
protocole parmi un protocole SSL et un protocole 
TLS. 

8. Procede selon la revendication 6, dans lequel I'exa- 
men (330) comporte en outre une identification du 
service VPN transparent eloigne (402) en tant que 
service qui gere le trafic de VPN pour le client eloigne 
(420). 

9. Procede selon la revendication 6, comportant en 
outre les etapes suivantes : 

recevoir une communication de reponse prove- 
nant du client eloigne (420) via le service VPN 



transparent eloigne (402), si la communication 
a ete envoyee via le VPN car elle ne pouvait pas 
etre satisfaite a partir du cache local (401 C) ; 
transformer la reponse sur la base des formats 
5 du VPN ; et 

delivrer la reponse transformee au client local. 

10. Procede selon la revendication 6 comportant en 
outre la gestion (321) de communications supple- 

10 mentaires associees au VPN a partir d'un ou de plu- 
sieurs clients locaux differents (410), qui sont adres- 
sees entre un ou plusieurs clients eloignes differents 
(420), dans lequel le service VPN transparent eloi- 
gne (402) gere les communications supplementaires 

15 au nom d'un ou plusieurs clients eloignes differents. 

11. Procede selon la revendication 6, dans lequel la re- 
ception comporte en outre I'interception (310) de la 
communication apres avoir detecte que le client local 

20 transmet la communication avec un protocole de 
transfert non hypertexte. 

12. Procede selon la revendication 6, comportant en 
outre ['interaction (341) avec le service VPN trans- 

25 parent eloigne avec des certificats signes mutuelle- 
ment qui sont echanges entre les services VPN 
transparent eloigne et local pendant les interactions. 

13. Systeme de gestion (400) de reseau prive virtuel 
30 (VPN), dans lequel ni le ou les clients locaux (410) 

ni le ou les clients eloignes (420) ne sont pre-confi- 
gures avec des capacites VPN ou un logiciel spe- 
cialise pour traiter des communications VPN, 
comportant : 

35 

un service VPN transparent local (401) ; 
un proxy, routeur ou commutateur avant ou 
transparent local (401 B), adapte pour detecter 
une communication provenant d'un client local 

*o a chaque fois que le client local essaye d'en- 

voyer la communication de maniere non secu- 
risee sur un reseau a un client eloigne via un 
port de communications local predefini specifi- 
que (401A) et adapte pour intercepter la com- 

45 munication detectee et pour la diriger (21 1 ) du 

proxy, du routeur ou du commutateur local vers 
le service VPN transparent local ; 
un service VPN transparent eloigne (402) ; 
un proxy de transfert ou transparent eloigne, un 

50 routeur eloigne ou un commutateur eloigne 

(402B), adapte pour detecter une communica- 
tion provenant d'un client eloigne a chaque fois 
que le client eloigne essaye d'envoyer la com- 
munication de maniere non securisee sur le re- 

55 seau a un client local via un port de communi- 

cations eloigne predefini specifique (402A), et 
adapte pour intercepter la communication de- 
tectee et pour la diriger (21 1 ) du proxy, routeur 
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ou commutateur eloigne vers le service VPN 
transparent eloigne. 

14. Systeme de gestion de VPN selon la revendication 

13, comportant en outre 5 

un cache local (401 C) ; 

dans lequel un service VPN transparent local (401) 
intercepte et gere le trafic VPN au nom d'un ou plu- w 
sieurs clients locaux (410), et dessert des commu- 
nications de ces clients locaux avec des donnees 
dans le cache local (401 C), si disponibles, et si les 
donnees ne sont pas disponibles dans le cache local, 
le service VPN transparent local transmet les com- 15 
munications de maniere securisee au service VPN 
transparent eloigne pour une livraison et une des- 
serte par un ou plusieurs clients eloignes (420) que 
le service VPN transparent eloigne (402) gere. 

20 

15. Systeme de gestion de VPN selon la revendication 
13, dans lequel le service VPN transparent local 
(401) et le service VPN transparent eloigne (402) 
interagissent via au moins un protocole parmi le pro- 
tocol SSL et le protocole TLS. 25 

16. Systeme de gestion de VPN selon la revendication 
13, dans lequel le service VPN transparent local 

(1 02. 401 ) intercepte le trafic VPN local au nom d'un 

ou de plusieurs clients locaux (101, 410) en exami- 30 
nant des communications du protocole TCP ou du 
protocole FTP provenant d'un ou de plusieurs clients 
locaux. 

17. Systeme de gestion de VPN selon la revendication 35 
13, dans lequel des communications entre les ser- 
vices VPN transparent local (102 et 401) et eloigne 

(1 03. 402) se produisent avec des certificats echan- 
ges mutuellement. 

40 

18. Systeme de gestion de VPN selon la revendication 
13, dans lequel le systeme reside sur un serveur et 
dessert une pluralite de clients locaux (410) associes 
aux communications VPN. 

45 

19. Systeme de gestion de VPN selon la revendication 
13, dans lequel le systeme reside sur un client uni- 
que. 

20. Programme informatique qui, lorsqu'il est execute 50 
sur un ordinateur ou un reseau informatique, met en 
oeuvre le precede selon Tune quelconque des re- 
vendications 1 a 12. 

21. Programme informatique selon la revendication 20, 55 
lorsque memorise sur un support accessible par ma- 
chine. 
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